The field of the disclosure relates generally to management of computer networks, and more particularly, to management of certificates and/or certificate authorities among clients and ecosystems over such networks.
In conventional networks that utilize certificate authorities, typically a direct relationship exists between a Certificate Authority (CA) and a client. That is, interactions between the CA and the client are handled directly. However, when a large ecosystem (e.g., a coalition of companies in the same industry) must be managed, conventional systems sometimes utilize a specialty Certificate Management Authority (CMA) company to manage the multiple and changing certificates issued among the ecosystem. In such circumstances, the CMA must not only understand the industry needs, but also must set and enforce security standards (cryptographic algorithms, encoding, naming, etc.). When a third party such as the CMA is involved, many cryptographic standards, processes and protocols, which are typically established for only two particular parties (e.g., the CA and the client), are no longer applicable. In other words, the cryptographic standards particular certificate does not consider the relationship of the CMA to the other parties, and therefore such three-party arrangements lack in trust and security.
FIG. 1 is a schematic illustration of a conventional certificate management system 100. System 100 includes an ecosystem member 102, a specialist (or consultant) 104 a CA 106 having an electronic interface 108, and an embedded device or application 110, and an ecosystem 112. For simplicity of explanation, one of ordinary skill in the art will understand that all of these elements of system 100 represent various electronic devices, computer systems, and/or software applications communicating over electronic network (cable, wired, and or wireless, etc.), and are not intended to refer to natural persons. In an exemplary embodiment, CA 106 may be a certificate authority hosting root certificate.
In operation, ecosystem member 102 transmits a communication 114 to specialist 104 to build an interaction with electronic interface 108 of CA 106. Once such interaction is established, ecosystem member 102 transmits a request 116 to CA 106 for one or more certificates (not shown) including one or more of related metadata, specialized request information and formats, and a Public Key (not shown) for ecosystem member 102. In an exemplary embodiment, request 116 is received by electronic interface 108 over an electronic network of system 100. Once request 116 is received by CA 106, CA 106 transmits a response 118 to ecosystem member 102 to acknowledge receipt of the certificate request (i.e., request 116).
After request 116 is received, CA 106 then further aggregates a certificate package, which includes an encryption 120 of the certificate package with a Private Key (not shown) of CA 106, and the Public Key of the ecosystem member 102 from request 116. Once the certificate package is aggregated, CA 106 transmits aggregated certificate package 122 to ecosystem member 102. Once aggregated certificate package 122 is received by ecosystem member 102, ecosystem member 102 performs a decryption 124 on aggregated certificate package 122 using the Private Key of CA 106. Ecosystem member 102 then transmits an acknowledgment 126 to CA 106 that acknowledges the receipt and successful decryption of aggregated certificate package 122.
After successful decryption 124 of aggregated certificate package 122, ecosystem member 102 then performs an embedding 128 of one or more decrypted certificates into individual embedded devices and/or software applications 110 associated with ecosystem member 102. Once so embedded, one or more of embedded devices and/or software applications 110 are subject to a deployment 130 within ecosystem 112, which requires the specific embedded certificates, along with the appropriate certificate chain and root of trust.
According to this conventional system 100, however, a change to CA 106, such as for a new single-source or as a second-source provider, ecosystem member 102 is required to further consult with specialist 104 to update interactions with CA 106, through electronic interface 108. Consultation with specialist 104 is also required when CA 106 changes electronic interface 108, which is known to happen frequently in the industry, or if there are any changes or concerns with electronic interface 108 coming from ecosystem member 102. Each of these consultations can involve an expensive and time-consuming process which is unique for each and every ecosystem member 102 affected by changes to CA 106 or electronic interface 108.